home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17821 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.8 KB  |  96 lines

  1. Path: news.th-darmstadt.de!news
  2. From: enno@inferenzsysteme.informatik.th-darmstadt.de (Enno Sandner)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Circular Usage (forward declaration?)
  5. Date: 17 Apr 1996 20:04:01 +0200
  6. Organization: Fachbereich Informatik, TH Darmstadt
  7. Sender: enno@kitz.inferenzsysteme.informatik.th-darmstadt.de
  8. Message-ID: <lt3f62u3qm.fsf@kitz.inferenzsysteme.informatik.th-darmstadt.de>
  9. References: <MRW.96Apr16184800@tobago.siemens.ch>
  10.     <ltu3ykovzc.fsf@kitz.inferenzsysteme.informatik.th-darmstadt.de>
  11.     <31747631.5970@datalytics.com> <MRW.96Apr17104121@tobago.siemens.ch>
  12. NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
  13. In-reply-to: mrw@tobago.siemens.ch's message of 17 Apr 1996 08:41:21 GMT
  14. X-Newsreader: Gnus v5.1
  15.  
  16. In article <MRW.96Apr17104121@tobago.siemens.ch> mrw@tobago.siemens.ch (Waeckerlin Marc) writes:
  17.  
  18.    Thank you for the answers.
  19.  
  20.    I know this way, but it does not work in my case, since the members "x"
  21.    absolutely must be no pointers.
  22.    Speaking more exactly, they are pointers, but they are smart pointers.
  23.    In another example, you could get somnething like this, where "CPointer"
  24.    is a smart pointer:
  25.  
  26.    class CCompany
  27.    {
  28.      protected:
  29.  
  30.        CPointer<CEmployee> m_emp;
  31.  
  32.      public:
  33.  
  34.        set(CEmployee &p_emp)
  35.        {
  36.      m_emp = &p_emp;
  37.        }
  38.    };
  39.  
  40.  
  41.    class CEmployee
  42.    {
  43.      protected:
  44.  
  45.        CPointer<CCompany> m_comp;
  46.  
  47.      public:
  48.  
  49.        set(CCompany &p_comp)
  50.        {
  51.      m_comp = &p_comp;
  52.        }
  53.    };
  54.  
  55. If your smart-pointer can handle polymorphism, you may introduce abstract
  56. classes representing the interfaces for the concrete classes CCompany and
  57. CEmployee, say CCompanyItf and CEmployeeItf. The concrete classes would
  58. inherit public from these abstract classes to express the conformance to
  59. the described interfaces. Finally CCompany would maintain a pointer to a
  60. CEmployeeItf and CEmployee a pointer to CCompanyItf instead. This adds some
  61. slightly additional overhead, because each function will become virtual.
  62. Or you may use the common technique to hide implementation details by
  63. putting all data-members in a dynamicly allocated structure. For instance
  64. the modified CCompany class may look like
  65.  
  66. headerfile:
  67. class CCompanyImp;
  68.  
  69. class CCompany {
  70.   protected:
  71.     CCompanyImp* imp_;
  72.  
  73.   public:
  74.     CCompany();
  75.     CCompany(const CCompany&);
  76.     ~CCompany();
  77.     CCompany& operator = (const CCompany&);
  78.     void set(CEmployee &p_emp);
  79. };
  80.  
  81. implementation-file:
  82. class CCompanyItf {
  83.  friend class CCompany;
  84.  CPointer<CEmployee> m_emp;
  85. };
  86.  
  87. CCompany :: CCompany() : imp_(new CCompanyImp()) {}
  88. // copy-ctor, dtor, assignment-op left out ...
  89. void CCompany :: set(CEmployee& p_emp) { imp_->m_emp=p_emp; }
  90.  
  91. Of course this also adds some overhead for dereferencing the pointer.
  92. But both are IMO reasonable solutions to resolve the problem of cyclic
  93. dependencies.
  94.  
  95.     Enno
  96.